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Abstract.  We  present  a  language  "Hardware  viewed  as  Objects  and  Processes  (HOP)  for 
specifying  the  structure,  behavior,  and  timing  of  hardware  systems.  HOP  embodies  a  simple 
process  model  for  lock-step  synchronous  processes.  An  absproc  specification  written  in  HOP 
describes  the  externally  observable  behavior  of  a  process.  A  collection  of  sbsprocs  may  be 
composed  to  form  a  larger  process,  using  the  operators  parallel  composition,  renaming,  and 
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y~ — hr  this  paper ^we  prescnbjhe  communication  primitives  of  HOP,  illustrate  HOP  through 
several  examples,  and  then  present  its  operational  semantics.  Then  we  present  the  role  played 
by  HOP  in  in  three  VLSI  design  activities:  (i)  inferring  concise  behavioral  descriptions  of 
systems  from  their  structural  descriptions;  (ii)  static  detection  of  control  timing  errors  during 
behavioral  infcrrence;  (iii)  productive  and  runtime  efficient  functional  simulation  using  the 
inferred  behavior.  ^  )  , _ _ 
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1  Introduction 


The  use  of  formal  specifications  for  specifying,  verifying,  manually  designing,  and  automat¬ 
ically  synthesizing  hardware  systems  is  becoming  widespread.  Not  only  are  there  different 
formal  specification  languages,  but  also  there  are  a  number  of  different  formalisms  in  use: 
Functional  Programming  [21 ,35]  Prolog  [38],  Petri  Nets  [7],  Temporal  Logic  [4],  various  Calculii 
of  Communicating  Systems  [26,16]  Trace  Theory  [36],  Higher  Order  Logic  [6,22],  Algebraic 
Specifications  and  Equational  Techniques  [14,37,32],  Synchronized  Transition  Systems  [9],  and 
Path  Expressions  [1],  to  name  a  few.  Enough  impressive  results  have  been  demonstrated  to 
justify  the  use  of  formal  specifications  for  VLSI  design.  However,  as  will  be  discussed  momen¬ 
tarily,  many  problems  in  the  use  of  formal  specifications  for  VLSI  design  remain  unsolved. 
More  importantly,  many  indirect  benefits  of  writing  formal  specifications— -especially  for  un¬ 
ambiguous  documentation  of  designs,  supporting  design  automation  activities,  etc. — have  not 
been  emphasized  enough. 

In  this  paper,  we  present  a  simple  and  formal  Hardware  Description  Language  (HDL) 
“HOP”  (Hardware  viewed  as  Objects  and  Processes),  and  present  its  role  in  three  VLSI 
design  activities:  (i)  inferring  concise  behavioral  descriptions  of  systems  from  their  structural 
descriptions;  this  is  done  using  an  algorithm  called  PARCOMP;  (ii)  the  detection  of  control 
timing  errors  during  behavioral  inference;  (iii)  productive  and  runtime  efficient  functional 
simulation  using  the  inferred  behavior.  The  main  contributions  of  this  work  are  believed  to 
be:  (i)  doing  the  above  three  tasks  by  capitalizing  on  the  the  formal  semantic  rules  of  the 
language  HOP;  (ii)  demonstrating  the  utility  of  these  ideas  on  a  working  implementation  of 
HOP  and  PARCOMP. 

Despite  being  a  formal  specification  language,  HOP  specifications  are  easy  to  understand. 
HOP  can  intuitively  model  the  intricate  timing  protocols  that  synchronous  hardware  systems 
exhibit.  It  can  model  commonly  used  structures  in  VLSI,  such  as  through  connections  and  reg¬ 
ular  arrays,  directly.  It  has  the  ability  to  highlight  timing/control  aspects,  and  function/data 
aspects  separately ,  so  that  designers  may  focus  on  one  aspect  at  a  time.  Last,  but  not  the 
least,  HOP  has  a  simple  semantics  that  can  be  exploited  for  doing  PARCOMP,  functional 
simulation,  and  design  verification. 

We  now  present  the  motivation  for  designing  HOP,  and  our  specific  results  to  date. 
Motivation 

Specifying  the  timing  protocols  and  the  functional  behavior  of  synchronous  systems  with 
clarity  is  quite  important.  More  importantly,  the  functional  details  are  also  intricately  inter¬ 
woven  with  timing.  The  examples  in  this  paper  are  chosen  to  illustrate  the  clarity  with  which 
HOP  can  specify  such  intricate  behaviors. 

It  has  been  reported  that  the  complete  formal  verification  of  even  extremely  simple  ICs  is 
at  present  a  challenging  task  [8].  More  importantly,  impressive  results  with  theorem  provers 
have  almost  always  been  exhibited  by  persons  who  played  a  major  role  in  developing  the 
theorem  prover  (and  hence  knew  its  innards) — not  by  end-users  of  theorem  provers.  Until 
these  situations  change  significantly,  the  main  uses  of  formal  specifications  will  be  for  its 
indirect  benefits — better  understanding  of  designs,  better  communication  among  hardware 
designers  and  systems-software  writers,  and  support  for  specification-driven  design  automation 
activities.  In  this  paper,  we  focus  on  such  indirect  benefits  of  using  HOP. 
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Specific  Result*  Reported,  and  Organization  of  the  Paper 

•  Section  2  presents  the  HOP  language,  and  illustrates  the  various  language  concepts 
introduced  through  the  example  of  a  simple  stack. 

•  Section  3  presents  the  operational  semantics  of  HOP.  (Note:  If  the  reader  were  to  feel 
intimidated  by  the  formal  notation  in  this  section,  then  he/she  may  read  this  section 
cursorily  without  much  loss.) 

•  Section  4  illustrates  PARCOMP  on  a  simple  example,  and  also  illustrates  how  each  rule 
of  the  the  operational  semantics  are  used. 

•  Section  5  presents  various  experiments  conducted  using  PARCOMP.  First,  we  present 
the  result  of  performing  PARCOMP  on  the  stack  module.  We  then  deliberately  intro¬ 
duce  errors  into  the  stack  controller,  and  show  how  PARCOMP  can  (often)  reveal  these 
errors.  We  then  show  how  the  stack  may  be  pipelined,  and  present  the  behavior  of  the 
pipelined  stack  inferred  using  PARCOMP.  We  also  show  how  PARCOMP  can  be  used 
to  make  functional  simulation  more  productive  and  efficient. 

•  Section  6  presents  a  divide-and-conquer  version  of  PARCOMP.  This  technique  exploits 
two  disparate  facts:  (i)  that  the  PARCOMP  operator  is  commutative  and  associative; 
(ii)  that  VLSI  systems  have  a  high  replication  factor — i.e.  the  ratio  of  the  total  number 
of  modules  to  the  number  of  different  modules. 

•  Section  7  presents  our  conclusions;  In  appendix  A.2,  we  briefly  describe  the  HOP  design 
system  that  was  used  to  produce  the  results  reported. 

1.1  Understanding  the  Modeling  Philosophy  of  HOP 

One  significant  aspect  of  HOP  is  that  it  emphasizes  the  use  of  abstract  data  types  for  hardware 
modeling.  This  was  motivated  by  the  positive  results  from  the  first  author's  past  work  with 
the  SBL  language  [14,10,11].  We  now  present  through  a  simple  example  the  essence  of  HOP. 

Consider  a  stack  data  type  implementation  that  uses  a  counter  to  implement  the  stack 
pointer  and  a  memory  array  to  implement  the  stack  locations.  If  such  a  stack  were  to  be 
specified  as  a  “software  data  type",  the  definitions  of  the  stack  operations  (say  push,  pop, 
and  top)  would  be  provided  via  functional  expressions  that  use  operators  on  the  stack  pointer 
and  memory  types.  The  stack  state  would  be  modeled  as  a  tuple  <  dr, mem  >,  consisting 
of  the  counter  and  memory  states.  The  operation  push  can  be  modeled  via  the  functional 
expression: 

push(<  mem, dr  >,v)  «=<  tvrite(mem,read(dr),  v),  addl(dr)  >  . 

This  says  that  the  memory  state  should  advance  to  write(mem,  read(dr),  v)  and  that  the 
counter  state  should  advance  to  addl(ctr).  This  view  of  hardware  systems — that  they  imple¬ 
ment  a  collection  of  intuitive  to  grasp  mathematical  functions — is  also  taken  in  [21]. 

As  we  showed  in  our  past  work  with  SBL,  these  kinds  of  specifications  may  be  implemented 
in  hardware  by  synthesizing  controller  modules  that  “fire"  the  operations  write,  read ,  uddl, 
etc.  in  an  applicative  order  (actually  the  in  situ  evaluation  order  [13],  which  is  slightly  more 
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restrictive  than  the  applicative  order).  However  for  this  technique  to  be  widely  applicable, 
it  should  be  possible  to  view  a  wide  variety  of  hardware  systems  as  data  types.  This  isn’t 
natural  often,  especially  where  control  aspects  dominate.  More  seriously,  the  “software  data 
type  like”  approach  does  not  permit  the  specification  of  complex  timings  naturally,  although 
it  has  been  attempted  [10,34]. 

The  Concept  of  “Modes  of  Behavior” 

HOP  takes  a  crucial  departure  from  the  functional/data- type  view  of  hardware.  Rather  than 
considering  data- type  operations ,  or  /unctions,  we  focus  on  modes  of  behavior.  A  modes  of 
behavior  is  a  more  general  notion  than  that  of  an  operation.  It  is  like  a  trace  of  [17].  A  mode 
of  behavior  is  best  characterized  as  a  finitely  describable  (and  often  finite)  sequence  of  events, 
data  input  actions ,  and  data  output  actions. 

For  example,  consider  a  memory  data  type  that  has  a  read  operation.  A  realization  of  the 
memory  has  many  possible  (depending  on  design  decisions  such  as  pipelining  etc.)  read  modes 
of  behaviors.  One  such  mode  of  behavior  consist  of  a  read  trigger  event,  a  data  input  action 
corresponding  to  the  supply  of  address,  and  a  data  output  action  corresponding  to  the  output 
of  the  read  data.  These  three  actions  may  come  in  any  order,  with  the  only  constraint  that 
the  ith  read  event  trigger  and  ith  address  input  must  precede  the  ith  data  output.  Clearly, 
many  different  modes  of  behavior  are  admitted  by  this  (rather  loose)  constraint.  For  example, 
a  memory  with  a  pipelined  implementation  of  the  read  operation  defines  one  specific  mode  of 
behavior  for  read.  A  memory  that  queues  upto  (say)  12  read  requests  before  it  outputs  any 
data  item,  defines  another  mode  of  behavior.  So  not  only  do  we  need  mathematical  functions 
to  define  I/O  mappings  from  states  and  inputs  to  new  states  and  outputs,  but  we  also  need 
a  way  to  capture  the  timings  involved.  The  functions  and  their  inputs  and  outputs  must  be 
inter- woven  with  the  timing  aspects  of  the  mode  of  behavior. 

Specifying  Modes  of  Behavior  in  HOP 

HOP  is  intended  to  capture  modes  of  behavior  directly.  It  does  so  by  introducing  a  protocol 
specification  section.  Let  us  understand  the  way  protocol  sections  are  written.  Consider  the 
pipelined  read  operation,  again.  One  of  the  most  natural  ways  of  explaining  the  behavior 
of  such  an  operation  to  a  person  is  by  drawing  the  picture  of  a  Deterministic  Finite-state 
Automaton  (DFA).  One  may  ask,  “why  not  use  DFAs  directly  for  specifying  hardware”? 

This  question  is  being  considered  mainly  for  two  reasons.  For  one,  in  this  paper  we 
portray  HOP  process  specifications  through  “DFA-like  graphs”,  and  we  want  to  avoid  the 
readers  trivializing  HOP  as  a  DFA  specification  language.  For  another,  it  is  widely  known 
from  human  studies  that  explaining  a  new  concept  by  first  presenting  a  related  but  much 
weaker  concept,  and  then  showing  that  such  a  concept  won’t  suffice,  is  very  effective. 

The  following  are  some  of  the  important  reasons: 

•  DFA  based  languages  cannot  handle  data  related  aspects  well;  modeling  data  path  states 
as  automaton  states  results  in  an  explosion  of  the  number  of  states.  In  contrast,  in  HOP 
we  use  high-level  abstract  data  type  (ADT)  objects  to  model  data  related  aspects.  Only 
control  states  are  explicitly  modeled.  Data  related  aspects  are  captured  by  annotating 
the  control  graph.  By  doing  so,  both  the  data  and  control  related  aspects  of  a  system 
are  completely  specified  at  a  high  level. 
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•  The  use  of  ADTs  in  HOP  Addresses  systems  engineering  issues  such  as  reported  in  [3]. 
Hardware  systems  are  developed  over  a  long  time,  and  initially,  only  the  “what"  aspects 
(requirements)  on  the  system’s  behavior  are  known.  High-level  ADTs  can  be  used  to 
write  a  requirements  specification  of  the  system — and  refined  later  when  design  details 
become  known.  These  benefits  are  not  available  if  DFA  based  models  are  used. 

•  Similar  to  the  act  of  introducing  ADTs,  HOP  allows  writing  requirements  specifications 
for  the  temporal  aspects  of  a  system  using  the  concept  of  events. 

•  HOP’s  process  model  addresses  design  issues  such  as  the  connection  of  modules  via 
busses,  as  well  as  the  related  issue  of  strengths^). 

•  HOP’s  process  model  is  based  on  the  three  fundamental  operations  of  hierarchical  system 
design — composition ,  hiding ,  and  renaming — as  identified  by  Milner[29].  Since  HOP  is 
a  high-level  specification  language  for  synchronous  systems,  the  study  of  these  (and 
related)  operations  provides  a  design  theory  for  synchronous  VLSI  systems. 

•  Despite  basing  HOP  on  the  above  elementary  mathematical  operators,  we  do  not  propose 
that  users  program  directly  using  these  operators.  Instead,  in  the  HOP  language  we 
provide  high  level  constructs  that  could  be  easily  translated  to  a  (much  larger  and 
relatively  very  low  level)  description  using  these  elementary  operators.  Thus,  ease  of  use 
as  well  as  formal  semantics  are  both  provided. 


1.2  Related  Work 

We  compare  HOP  with  other  works  on  two  aspects:  (i)  in  its  capability  to  specify  complex 
timing  and  functional  behaviors;  (ii)  in  its  capacity  to  perform  PARCOMP,  simulation  based 
on  PARCOMP,  and  the  detection  of  control  timing  errors.  Many  features  of  HOP  have  been 
omitted  here,  but  have  been  reported  elsewhere[l2). 

HOP  is  close  in  some  respects  to  the  work  of  Milne  [26].  The  main  differences  with  it  are 
the  following: 

1.  In  HOP,  value  communication  has  been  decoupled  from  synchronization.  The  advantages 
of  doing  so  are  discussed  in  section  2. 

2.  We  emphasis  the  modeling  of  value  communications  and  data  path  state  changes  in 
a  simple,  yet  powerful,  abstract  data  type  oriented  functional  language.  This  is  not 
addressed  in  [26]. 

3.  HOP  adopts  a  specific  timing  model — that  of  lock-step  synchronous  processes.  HOP 
processes  are  deterministic.  These  decisions  contribute  directly  to  the  simplicity  of  the 
language  and  makes  specification  driven  design  more  practical. 

On  the  other  hand,  Circa!  includes  primitives  that  are  more  elementary,  and  hence  more 
powerful  at  the  expense  of  being  of  lower-level. 

4.  HOP  is  well  suited  for  describing  synchronous  hardware  systems.  A  large  majority  of 
VLSI  systems  are  synchronous.  In  this  realm,  we  have  conducted  a  more  thorough 
investigation  of  many  practical  aspects  of  VLSI  design. 
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ABSPROC  <ModuleNaa«>  [<for»al  paraas  pertaining  to  liru  4  typ«s>] 
CONST  <list  of  eonatanta  of  the  ease  value > 

TYPE  <liat  of  type  idantifiara  of  the  aaaa  typa> 

PORT  <liat  of  porta  of  tha  ease  type> 

CLOCK  <a  clock  agant  and  tha  porta  imported  from  it> 

EVENT  <evente  and  their  ancodinga  in  terma  of  port  values> 
PROTOCOL  <a  liat  of  procaaa  dafinitiona> 

DEFUN  <a  liat  of  function  definitiona> 

END  <ModulaNama> 


Figure  1:  The  Skeleton  of  an  Absproc  Specification 

HOP  is  different  from  more  traditional  languages  (e.g.  VHDL[18],  Karl[30],  and  ISPS[2]) 
in  many  ways,  the  most  important  being  the  following:  (i)  HOP  is  much  simpler  than  these 
languages,  and  has  an  equally  simple  formal  semantic  definition;  (ii)  The  view  of  hardware 
as  communicating  processes  is  attractive  in  many  ways  than  modeling  hardware  behavior 
through  traditional  imperative  constructs  (procedural  or  non* procedural  descriptions).  By 
creating  HOP,  we  are  not  discarding  or  ignoring  ongoing  efforts  towards  developing  standard 
HDLs  such  as  VHDL.  Our  objective  is  to  experiment  with  interesting  ideas  not  present  in 
such  standard  languages,  and  the  results  may  one  day  benefit  future  versions  of  VHDL. 

PARCOMP,  as  well  as  its  planned  uses,  are  similar  to  the  work  reported  in  [15],  and 
to  the  idea  of  constructive  simulation  reported  in  [27].  However  our  work  is  done  for  a 
much  higher  level  language  that  includes  user-defined  abstract  data  types.  Our  algorithm 
embodies  useful  static  checks  of  timing  protocols.  Our  algorithm  capitalizes  on  the  structural 
information  (specifically,  knowledge  about  events  that  are  completely  hidden  within  a  module) 
to  save  on  computation  time.  This  is  accomplished  thus  (explained  in  detail  later):  “states 
reachable  via  transitions  labeled  by  unsynchronized  and  hidden  events  are  never  visited,  and 
consequently  the  search-space  is  pruned."  Further,  we  have  developed  a  version  of  PARCOMP 
called  PARCOMP-DC  that  can  exploit  the  regularity  of  vecprocs  using  a  divide-and-conquer 
technique  (section  6).  Finally,  PARCOMP  can  be  used  to  save  the  time  of  simulation;  we 
can  perform  a  “pre  simulation"  of  the  tester  and  the  testee  using  PARCOMP,  and  run  the 
resultant  process.  These  computational-effort  saving  measures  are  believed  to  be  new. 


2  The  HOP  Language 

The  basic  unit  of  specification  in  HOP  is  the  module.  The  external  attributes  of  a  module 
are: 

•  Zero  or  more  uni-  or  bi-directional  data  ports; 

•  Zero  or  more  uni-directional  events; 

•  An  external  protocol  specification. 

A  module  specified  as  a  black  box  is  called  an  absproc,  standing  for  abstract  process. 
The  skeleton  of  an  ABSPROC  is  shown  in  figure  1.  A  module  specified  as  a  network  of 
subprocesses  is  called  a  realproc,  the  skeleton  of  which  appears  in  figure  2.  (Note:  For  ease  of 
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REALPROC  <ModulaNama>  [<  formal  par  ami  pertaining  to  sizas  ft  typea>] 
CONST  <liat  of  constants  of  the  aama  valua> 

TYPE  <list  of  type  identifiers  of  tha  aama  typa> 

PORT  <tha  external  porta  of  tha  modula  being  dafinad> 

SUBPROCESS  <instantiations  of  prav.  defined  aba/raal/vac  procaaaaa> 
CONNECT  <tha  aat  of  interconnections  among  tha  subprocesses> 

END  <ModulaNama> 


Figure  2:  The  Skeleton  of  an  Realproc  Specification 

VECPROC  <ModulaNama>  [<formal  parama  pertaining  to  aizaa  ft  typaa>] 
CONST  <liat  of  conatanta  of  tha  aama  value> 

TYPE  <liat  of  type  idantifiara  of  tha  aama  typa> 

PORT  <tha  axtarnal  porta  of  tha  module  baing  defined> 

SUBPROCESS  <inatantiationa  of  prav.  dafinad  aba/raal/vac  procaaaaa> 
DIMENSIONS  <tha  SIZES  of  each  diman* ions  of  regularity> 

CONNECT  <interconnectiona  batn.  aubprocaaaaa ,  via  recurrence  eqns.> 
END  <ModuleName> 


Figure  3:  The  Skeleton  of  a  Vecproc  Specification 

parsing,  currently  we  use  a  lisp-like  syntax  for  HOP;  we  have  hand  edited  Almost  all  syntactic 
descriptions  in  this  paper  to  an  easier-to-understand  higher-level  syntax.) 

Since  topologically  regular  realprocs  (t.g.  single  and  two-dimensional  arrays  of  modules) 
occur  very  frequently  in  practice,  we  identify  a  sub-category  of  realprocs  called  vecprocs  (fig¬ 
ure  3).  Vecprocs  in  HOP  may  best  be  regarded  as  “arhythmic  arrays” — geometrically  regular 
arrays  in  which  computations  aren't  necessarily  regular,  or  rhythmic,  as  in  systolic  arrays.  A 
divide-and-conquer  version  of  PARCOMP  has  been  developed  for  Vecprocs  (section  6). 

A  realproc  is  built  using  one  or  more  absprocs  by  connecting  some  of  the  ports  and  events 
of  the  absprocs,  by  composing  the  external  protocols  of  the  absprocs,  and  by  internalizing 
(hiding)  some  of  the  events  and  ports  of  the  absprocs.  A  syntactically  sugered  notation 
(DATANODE  and  EVENTNODE  )  mitigates  the  burden  of  specifying  the  renaming  and  hiding  ([29]) 
information  for  large  systems.  A  vecproc  is  essentially  built  in  the  same  fashion;  however  a 
notation  based  on  recurrence  relations  is  provided  to  easily  specify  the  regular  placement  of 
modules  as  well  as  regular  interconnections  among  them. 

We  now  examine  the  specification  of  an  absproc  in  detail. 


2.1  Specifying  an  Absproc 

An  absproc  is  specified  by  its  ports,  its  events,  and  its  protocol. 

2.1.1  Ports  and  Value  Communication 
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Figure  4:  Use  of  Data  Assertions  aod  Queries  for  Value  Communication 

The  mechanism  of  synchronized  communication  as  used  in  [26]  does  not  accurately  model  the 
value  communication  in  hardware  systems.  As  an  example,  consider  figure  4  which  depicts 
a  system  consisting  of  two  producer  processes  Pi  and  P2  that  can  communicate  with  two 
consumer  processes  Cl  and  C2  over  a  bus.  In  this  system,  it  is  perfectly  acceptable  to  seek  the 
value  on  the  bus  while  there  are  no  simultaneous  writers,  or  vice  versa.  (The  former  case  could 
arise  in  VLSI  where  the  bus  has  a  “pull-up  transistor”,  for  example.)  It  is  even  permissible  to 
have  two  simultaneously  active  data  assertions  (say,  with  compatible  “strengths”  [5])  on  the 
bus. 

In  HOP,  value  communication  is  performed  through  a  mechanism  called  data  assertions 
and  queries.  A  data  assertion,  written  as  !p*E  ,  binds  an  individual  variable  p  representing  the 
output  port  to  the  value  E  at  the  time  the  data  assertion  is  made.  In  general,  data  assertions 
are  of  the  form  !p*E  until  «,  where  •  is  a  future  event,  where  the  until  operator  has  the 
same  meaning  as  the  until  operator  of  temporal  logic.  (Events  are  discussed  shortly.)  The 
lack  of  •'»  assertion  can  be  modeled  by  the  assertion  !p»Z,  where  Z  denotes  high  impedance. 
(For  a  bus  with  a  pull-up  transistor,  the  assertion  !p*v«akl  may  be  used.) 

A  data  query,  written  as  x«?q,  binds  x  to  the  value  bound  to  the  input  port  q  at  the  time 
the  query  is  made.  Multiple  data  assertions  (as  in  bus  connections)  end  up  asserting  the  feast 
upper  bound  (LUB)  of  the  asserted  values  on  the  port.  For  handling  multiple  data  assertions, 
the  type  of  values  communicable  via  ports  in  HOP  must  be  organized  into  a  strength  lattice 
[5].  For  example  the  bit  type  of  HOP  includes  the  weakest  value  Z  ( high-impedance ),  truth 
values  T  and  F,  an  unknown  value  U,  and  the  most  dominant  value  E,  error.  T,F,  and  U  are 
incomparable  amongst  themselves  and  lie  in-between  Z  and  E.  This  lattice  may  also  contain 
other  values,  such  as  veakl  and  veakO. 

The  above  mechanism  of  data  assertions  can  be  extended  for  modeling  bidirectional  devices 
such  as  pass  transistors,  ignoring  threshold  drops.  This  is  done  exactly  as  done  in  HOL[6], 
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by  asserting  that  the  source  and  drain  nodes  are  have  the  same  value  if  the  gate  is  held  at 
T.  Thus,  data  assertions  and  queries  permit  the  relational  style  of  specification  (i.e.  non- 
directional  interactions)  for  modeling  bidirectional  devices. 

Advantages  of  Data  Assertions  and  Queries 

By  having  two  processes  interaction  marhanUrm  (events  and  data  assertions)  we  have  es¬ 
sentially  separated  synchronization  from  communication.  We  now  show  through  an  example 
that  this  separation  is  advantageous  for  hardware  modeling.  Consider  a  counter  with  two 
commands  reset  and  up  that  are  triggered  via  events  with  the  same  names.  After  the  counter 
has  been  subject  to  the  reset  event  and  until  it  is  subject  to  the  up  event,  it  asserts  a  data 
of  0  on  its  output  port.  The  process  that  is  responsible  for  the  reset  and  the  up  events  can, 
after  it  has  applied  the  reset  event  (but  before  it  has  applied  the  up  event)  safely  assume  that 
the  output  will  be  well-defined  (and  equal  to  zero)  and  sample  this  output  as  many  times  as 
it  wishes,  without  any  participation  of  the  counter.  In  contrast,  if  value  communication  were 
bundled  up  with  rendezvous — as  is  the  case  with  CSP,  CCS,  and  Circal,  the  counter  would 
have  to  actually  rendezvous,  causing  the  counter  process  to  make  progress  in  its  computation. 
The  writer  of  the  counter  process  thus  has  to  anticipate  all  possible  places  where  such  ren¬ 
dezvous  are  possible,  and  make  provisions  for  them  in  the  specification.  Our  experience  is  that 
this  renders  hardware  specifications  unnatural  and  more  complicated.  In  contrast,  with  data 
assertions,  once  the  counter  has  asserted  0  on  its  output,  it  has  “discharged  all  its  duties”. 

The  spirit  in  which  this  extension  to  communication  mechanisms  was  made,  is  similar  to 
the  extension  made  by  Martin  to  CSP  to  include  Probes  [24].  Both  these  mechanisms  show 
that  concurrency  constructs  developed  for  concurrent  software  modeling  may  not  be  the  best 
possible  ones  for  hardware  modeling. 

2.1.2  Events 

Events  are  of  two  kinds:  input,  and  output.  An  input  event  •  (written  Ie)  denotes  a  condition 
that  a  module  senses  via  wires.  An  output  event  •  (written  Oe)  denotes  a  condition  that  a 
module  generates  via  wires.  Most  modules  have,  at  every  point  in  time,  a  set  of  events  GE 
(“good  events”)  that  would  steer  the  module  into  well  defined  modes  of  activity.  Modules  also 
have,  at  every  point  in  time,  a  set  of  events  BE  (“bad  events”)  for  which  they  do  not  have 
any  useful  behavior  defined.  We  call  the  GEs  at  every  point  in  time  as  the  “synchronization 
points”  of  the  module. 

Events  help  in  making  implicit  synchronization  points  explicit.  For  illustration,  consider 
a  clocked  synchronous  system  supporting  multiple  operations.  In  traditional  designs  of  syn¬ 
chronous  systems,  the  completion  of  an  operation  is  not  explicitly  notified,  but  is  tacitly 
assumed  after  the  elapse  of  a  certain  interval  of  time  from  the  start  of  the  operation.  However 
this  approach  is  worse  than  hard-wiring  literal  constants  in  programs  leading  to  programs  that 
are  hard  to  debug  or  modify.  A  better  approach  would  be  to  encourage  the  writers  of  module 
specifications  to  “highlight”  these  synchronization  points  by  introducing  events.  These  events 
may  be  thought  of  as  being  implemented  by  fictitious  control  and  status  wires. 

Events  have  a  conceptual  reality  even  at  very  early  stages  of  the  design;  however  they  attain 
implementations]  reality  (e.g.  “should  an  event  be  represented  in  unary,  or  in  binary?”,  etc.) 
only  much  later.  The  latter  decision  is  influenced  by  the  nature  of  the  controller,  and  this  is 
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typically  decided  much  later  in  a  design  life-cycle. 

Some  of  the  advantages  of  using  events  are: 

1.  It  becomes  possible  to  statically  check  for  sequencing  errors.  We  show  some  examples 
in  section  4. 

2.  It  highlights  the  allowed  modes  of  usage  of  a  module  Hardware  specifications  must  not 
merely  attempt  to  model  hardware  as  it  is;  rather  they  must  model  hardware  as  it  is 
expected  to  be  used.  Hardware  systems  have  astronomically  more  useless  combinations 
of  inputs  (as  well  as  sequences  of  combinations  of  inputs)  than  useful  ones. 

3.  As  digital  designs  evolve,  the  events  that  were  originally  thought  to  represent  fictitious 
control  wires  may  be  implemented  as  combinations  of  control  signals  and  clocks.  Combi¬ 
national  logic  necessary  to  decode  these  combinations  and  raise  the  corresponding  input 
event  will  be  tacitly  assumed,  and  not  modeled  explicitly.  This  is  of  advantage  on  two 
occasions:  (i)  when  these  encodings  haven't  been  decided;  (ii)  in  later  stages  of  a  design, 
when  these  encodings  would  be  excess  baggage  to  carry  around. 

4.  Event  connections  between  modules  is  achieved  via  renaming.  The  actual  implemen¬ 
tation  of  renaming  is  through  combinational  logic  that  translates  a  condition  in  one 
module  to  a  condition  in  another.  This  could  pave  the  way  for  the  synthesis  of  “glue 
logic"  that  connect  modules.  This  connection  between  a  language  operator  (renaming) 
and  its  hardware  interpretation  ( glue  logic)  is  natural. 

2.1.3  Data  Path  States 

In  the  specification  of  an  absproc,  the  data  path  state  of  the  system  being  specified  can 
be  modeled  using  an  appropriate  high-level  ADT.  In  our  experience,  (and  as  illustrated  by 
the  Roll  Back  Chip  (12]),  the  use  of  ADTs  having  simple  definitions  can  make  reference 
specifications  far  more  reliable  and  easier  to  understand. 

2.1.4  The  Timing  Model 

Time  is  a  way  to  order  events.  In  HOP,  processes  are  lockstep  synchronous.  Therefore  the 
time  of  every  process  advances  at  the  same  rate,  and  thus  the  event  ordering  we  have  can 
be  described  via  three  relations:  simultaneous,  before,  and  after.  A  HOP  specification  may 
or  may  not  refer  to  a  central  clock  depending  on  whether  it  models  a  clocked  synchronous 
system  or  a  unit-delay  combinational  system.  Currently  we  do  not  have  the  ability  to  model 
some  subsystems  at  the  unit-delay  combinational  level,  and  the  remaining  subsystems  at  the 
clocked  level.  We  hope  to  add  this  capability  later  on,  by  specifying  clock  periods  to  be  fixed 
integral  multiples  of  unit-delays  (an  idea  proposed  in  [19]). 

In  later  versions  of  HOP,  we  will  provide  a  “clock  library”,  i.e.  an  expandable  library 
of  various  clocking  schemes.  Each  entry  in  this  library  would  specify  a  clock  generator  of  a 
certain  kind;  for  instance  there  would  be  a  two-phase  clock  generator  in  this  library. 

2.1.5  An  Example  of  an  Absproc:  A  Pipelined  Memory 


9 


—  This  is  a  comment . 

ABSPROC  MEM  C  address.size,  data. size  :  int  ]  --  Note-0 
TYPE 

addressType  »  0  ..  ftddr«ss.sizs  -  1 
dataTypa  ■  0  . .  dfttft.sizs  -  1 
aeaoryType  *  array  [addressType]  of  dataTypa 
PORT 

?din,  idout  :  array  [data.size]  of  bit 
?ain  :  array  [address. size]  of  bit 
EVENT 

Xanop,  Iraad,  Xvrita  *  TBD 
PROTOCOL 

MEM  [as  :  asaoryTyps]  <■ 

Ianop  ->  MEM  [as] 

I  Xvrita,  va*?addr,  vd»?din  ->  MEM  [vrite(as,va,vd)] 

I  Iraad,  va*?addr  ->  MEMlCas,  va]  — “ —  Nota-1 

MEM1  [ms  :  aemoryTyp®,  oa  :  addrassTypa]  <■ 

Imnop,  !dout»rsad(ms,oa)  ->  MEM  [ms] 

I  Ivrite,  na»?addr,  vd»?din, 

!dout*r#ad(ms ,oa)  **>  MEM  [vritaCms ,na,vd)] 

I  Iraad,  na»?addr,  !dout»r#ad(ms,oa)  ->  MEMl[ms,  na] 

DEFUN 

vrita  : :  a  :  mamoryType,  a:  addrassTypa,  d: dataTypa  ->  al  :  aamoryTypa 
IF  (>  addr  aamSiza) 

(print  "Illegal  aeaory  address") 

(error-obj  aemType)  —  Note-2 

ELSE  (update-vector  aemType  a  a  d)  —  Note-3 


read  ::  m  :  aamoryTypa,  a:  addrassTypa  ->  d  :  dataTypa 
IF  (>  addr  aamSiza) 

(print  "Illagal  aamory  addrass") 

(arror-obj  int)  —  Note-2 

ELSE  (index-vector  aemType  a  a)  —  Note-3 


END  MEM 

—  Note-0 

—  Note-1 

—  Note-2 

—  Note-3 


Upper  and  Lover  Cases  are  Treated  the  Sana  in  HOP. 
vrita  (defined  in  DEFUN)  coaputes  the  nav  data  path  state, 
error-obj  is  supported  for  aeaoryType  by  our  ADT  library 
index-vector  and  update-vector  supported  by  aeaoryType 
vhich  is  defined  in  ADT  Library. 


Figure  5:  Specifications  of  a  Memory 
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Figure  6:  Depiction  of  the  PROTOCOL  Specification  of  MEM 

Consider  memory  module  MEM  which  has  an  address  input  port  ?addr,  a  data  input  ?din 
port,  and  a  data  output  port  Idout.  It  can,  in  its  “quiescent  state",  entertain  events  Inop, 
I  write,  and  Iread,  each  of  which  implement  the  commands  nop  (no  op),  write,  and  read. 
MEM  is  pipelined  thus:  the  delivery  of  the  result  of  a  read  request  is  overlapped  with  wait¬ 
ing  for  the  next  command.  Operation  write  as  well  as  operation  nop  (no  operation)  aren't 
pipelined. 

Let  us  study  figure  5.  The  header  declares  two  size  parameters.  The  PORT  section  declares 
the  I/O  ports.  The  EVENT  section  defines  three  events,  and  equates  them  to  “To  Be  Defined” 
(TBD).  Thus,  the  designer  of  MEM  doesn't  yet  care  about  the  encodings  of  the  control  inputs 
as  well  as  clocks  (if  any).  He/she  assumes  that  Iwrite,  Iread,  and  Inop  are  three  control  wires 
coining  in. 

Consider  the  PROTOCOL  section.  This  section  can  always  be  depicted  as  shown  in 
figure  6.  This  is  because  HOP  processes  are  finitely  representable  processes  (that  is,  they 
have  a  finite-state  control  skeleton,  and  this  control  skeleton  can  be  annotated  (“decorated”) 
with  data  path  state  changes  and  port  value  assertions.)  These  annotations  are  done  in  a 
purely  functional  notation.  The  functional  notation  improves  the  readability  and  conciseness 
of  specifications  considerably. 

The  functional  expressions  used  in  the  PROTOCOL  section  are  defined  in  the  DEFUN 
section  and/or  in  the  ADT  library.  Since  the  ADT  library  is  implemented  using  object  ori¬ 
ented  techniques  (our  technique:  “generic  types  are  classes”),  functions  are  overloaded  and 
dispatched  correctly.  Besides,  subtyping  is  available  for  free  through  class  inheritance.  The 
data  types  support  both  immutable  and  mutable  constructors.  We  are  currently  implement¬ 
ing  the  in  situ  evaluation  technique  [13]  to  use  mutable  constructors  whenever  possible,  while 
preserving  the  referential  transparency  of  HOP  functional  expressions. 

Let  us  study  the  text  of  the  PROTOCOL  section.  This  section  is  also  depicted  in  fig¬ 
ure  6.  In  this  figure,  we  have  annotated  the  transitions  with  current  events,  data  queries 
and  assertions,  and  the  next  data  path  state;  the  next  data  path  state  is  shown  only  if  it  is 
different  from  the  current  data  path  state.  Process  MEM  begins  in  control  state  MEM  and  in 
datapath  state  u.  It  offers  a  choice  of  three  events,  lanop,  I  write,  and  Iwrite.  If  none  of 
these  events  is  asserted  externally,  the  behavior  of  MEM  is  undefined.  Event  Innop  (realized 


11 


1 


by  the  unasserted  combination  of  the  read  and  write  controls)  causes  MEM  to  go  back  to  its 
top  control  state;  event  Xvrite  when  asserted  from  outside  must  be  accompanied  by  data 
assertions  va  on  the  ?addr  bus,  and  vd  on  the  data  bus  ?din.  It  causes  HEM  to  go  back  to 
the  control  state  MEM;  however  its  datapath  state  changes  to  vrite(as,va,vd).  Event  Xread 
must  be  accompanied  by  a  data  assertion  va  on  port  ?addr.  The  next  control  state  attained 
is  MEM1,  and  the  next  data  path  state  is  a  pair  [rna.va]. 

In  control  state  MEM1,  process  MEM1  is  in  data  path  state  [ns.oa] .  It  again  offers  the  choice 
of  three  events.  However  note  that  while  waiting  here,  the  data  assertion  !  dout»read  (ns ,  oa) 
is  made  (this  is  the  pipdining  effect).  This  assertion  corresponds  to  the  result  of  the  previously 
requested  read.  A  Xvrite  or  Xanop  takes  MEM1  back  to  MEM;  however  while  reads  keep  coming, 
MEM1  goes  back  to  MEM1. 

If  this  memory  were  to  be  used  in  a  clocked  system,  the  events  Ivrite,  Xread,  etc.  would 
be  generated  at  the  appropriate  clock  phases.  Thus,  details  such  as  multiphase  clocking  would 
be  described  in  the  EVENT  section  of  an  ABSPROC  by  replacing  the  “TBD”s  by  boolean 
expressions  involving  input  control  wires  and  clocks. 

We  assume  that  Xanop  is  a  special  event  that  is  asserted  if  none  of  the  other  events  are 
asserted.  Such  an  event  exists  in  most  modules,  and  should  be  defined  to  be  the  “unasserted 
combination  of  control+clock  inputs" . 


2.2  Specifying  Realprocs  and  Vecprocs 

A  realproc  specifies  a  system’s  realization.  As  an  example  let  us  use  the  memory  unit  in 
figure  5  to  build  a  stack  using  an  absproc  CTR  to  implement  the  stack  pointer  and  a  controller 
SCTL  to  control  the  stack.  The  design  of  the  stack  would  be  specified  by  writing  a  realproc 
specification,  as  shown  in  figure  9.  This  specification  captures  ihe  schematic  shown  in  figure  8. 
Let  us  now  discuss  the  sections  that  are  important  to  highlight  the  roles  played  by  a  Realproc. 

In  the  PORT  and  EVENT  sections,  the  external  ports  and  events  of  the  realproc  are 
declared.  All  other  ports  and  events  are  assumed  to  be  internal,  and  hence  hidden  from  the 
outside  world. 

In  the  SUBPROCESS  section  of  a  Realproc,  previously  specified  abs/real/vec  processes 
are  instantiated  to  the  required  sizes  as  well  as  types.  For  example  we  could  now  instantiate  a 
generic  stack  to  be  a  stack  over  bytes.  The  subprocesses  themselves  are  described  in  figure  7. 
We  present  only  the  PROTOCOL  section  of  the  subprocesses.  In  the  CONNECT  section, 
interconnections  between  ports  as  well  as  events  among  the  submodules,  and  between  the 
submodules  and  the  external  ports/events  of  the  stack  are  specified.  Semantically,  connections 
are  treated  as  renamings,  in  the  style  of  [29].  That  is,  connected  entities  are  renamed  to 
common  names  that  are  unique. 

Let  us  look  at  the  first  two  lines  of  the  DATANODE  subsection  of  the  CONNECT  section. 
(The  remainder  of  the  realproc  is  similar.)  The  node  that  connects  ?cdo  of  MEM  and  !  cdo 
of  CTR  is  hidden.  The  ?din  port  of  MEM  connects  to  ?din  of  the  stack. 
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CTR  [ca]  <*  Xcnop,  !cdo*cs  ->  CTR  tea] 

I  Xload,  vdin»?cdi  ->  CTR  [vdin] 

I  I up,  fcdo«ca  ->  CTR  [addl(ca)] 
I  Idovn,  !cdo«ca  ->  CTR  [aubl(ca)] 


SCTL  <■  Isnop,  Osmop,  Ocnop 
I  Iraaat,  Osmop,  Ocnop 
I  Ipuah,  Osmop,  Ocnop 
->  SCTL 

I  Ipop,  Osmop,  Ocnop 
I  It op,  Osmop,  Ocnop 


->  SCTL 

->  Oload,  Osmop  ->  SCTL 

->  Oup ,  Osmop  ->  Ovrita,  Ocnop 


->  Odovn,  Osmop  ->  SCTL 

->  Oread,  Ocnop  ->  Osmop,  Ocnop  ->  SCTL 


—  Nota:  All  the  "nop”  avant*  Have  to  ba  apacifiad  in  tha  praaant  varaion 

—  of  HOP.  Thaaa  could  ba  isiplicit  defaults ,  in  latar  vara  ions. 


Figure  7:  Stack's  Submodules:-  CTR:  An  up/down  counter;  SCTL:  Stack  Controller 
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ZrMct.Ipoak.Xpcp.lMp.Xaep 


Figure  8:  Schematic  of  the  Realproc  of  a  Stack 

3  Semantics  of  HOP 

3.1  An  Operational  Semantics  for  HOP 

In  this  section,  we  provide  an  operational  semantics  for  HOP,  using  many  of  the  conventions 
presented  by  Plotkin  [33]  for  writing  operational  definitions.  In  addition  to  describing  HOP 
unambiguously,  these  rules  form  the  basis  for  implementing  design  tools  based  on  HOP.  For 
instance,  PARCOMP  is  written  by  following  these  operational  rules.  Towards  the  end  of  this 
section,  we  also  briefly  touch  upon  the  subject  of  viewing  HOP  specifications  as  Temporal 
Logic  formulae. 

It  is  a  common  convention  when  providing  semantic  definitions  to  take  an  abstract  syntax 
of  the  language  in  question.  The  (hopefully  obvious)  translation  from  the  real  syntax  to  the 
abstract  syntax  is  not  discussed.  Also,  we  do  not  have  space  here  to  summarize  the  style  of 
writing  operational  definitions  as  presented  by  Plotkin  [33],  but  let  us  capture  the  main  idea. 
When  writing  operational  definitions  in  this  style,  we  try  to  provide  definitions  directly  using 
the  syntax  of  the  language,  through  certain  “symbol  pushing*  rules.  These  rules  are  to  be 
justified  independently  using  a  denotational  or  axiomatic  semantics;  however  once  so  justified, 
the  operational  “symbol  pushing*  rules  which  are  usually  much  simpler  can  be  used  in  the 
day-to-day  use  of  the  semantics.  This  is  precisely  our  approach.  This  is  why  we  have  provided 
a  temporal  logic  based  semantics  for  HOP  to  match  the  operational  rules  presented  here.  A 
brief  discussion  appears  at  the  end  of  this  section.  (Readers  who  find  this  section  hard  may 
cursorily  read  it.) 

The  operational  meaning  of  a  HOP  process  is  its  transition  relation  Proc  x  act  x  Proc 
where  the  domain  of  actions  for  a  process  is  act  and  that  of  processes  is  Proc.  This  relation 
is  defined  via  structural  induction  using  the  notation  ££  where  onfe  is  an  already  defined 
HOP  process  (the  “antecedent*),  and  conse  (the  “consequent*)  introduces  the  next  syntactic 
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REALPROC  stack  [<various  sizs  t  type  paraMters>] 
PORT 

Tcdi,  Tdin,  fdout  :  <suitable  types > 

EVERT 

Ireset,  I push,  I pop,  Itop,  Inop  ■  TBD 
SUBPROCESS  —  lots-4 

KEN  :  mb  [< actual  sizs  parameters)] 

CTR  :  ctr  [<actual  sizs  para*eters>] 

SCTL  :  sctl 

CORRECT 
DATANODE 
—  Hote-1 

HIDDEN  CORRECTS  ((MEN  ?cdo)  (CTR  lcdo)> 

Tdin  CORRECTS  ((HEM  Tdin)) 

Tcdi  CORRECTS  <(CTR  Tcdi)) 
idout  CORRECTS  ((HEM  idout)) 


EVERTRODE 


-  Notes-2,3 
HIDDEN  CONNECTS 
HIDDEN  CONNECTS 
HIDDEN  CONNECTS 
HIDDEN  CONNECTS 
HIDDEN  CONNECTS 
HIDDEN  CONNECTS 
HIDDEN  CONNECTS 


((MEN  Innop)  (SCTL  Oanop)) 
((HEM  Irsad)  (SCTL  Oraad)) 
((MEM  I writs)  (SCTL  Owrits)) 
((CTR  Icnop)  (SCTL  Ocnop)) 
((CTR  Hoad)  (SCTL  Oload)) 
((CTR  I up)  (SCTL  Oup)) 

((CTR  I down)  (SCTL  Odown)) 


I push  CONNECTS  ((SCTL  Ipush)) 

Xrssst  CONNECTS  ((SCTL  Irssst)) 

I pop  CONNECTS  ((SCTL  Xpop)) 

Itop  CONNECTS  ((SCTL  Itop)) 

Inop  CONNECTS  ((SCTL  Xsnop)) 

END  stack 

— Rots-1:  Each  lins  of  form  <srtport>/<hiddsn>  CORRECTS  <ports> 

— Note-2:  Each  lins  of  form  <ertevent>/<hidden>  CONNECTS  <events> 
— Nots-3:  Currently  ws  haws  to  specify  even  "obvious  defaults 

—  Later  such  defaults  (such  as  unasserted  values  of  events  etc.) 

—  will  be  automatically  provided. 

— Note-4:  In  general  nodule  instance  naaes  and  nodule  type  nanes 

—  are  different.  Here  they  are  the  sane.  E.g.  SCTL  and  sctl. 


Figure  9:  Realproc  of  a  Stack 
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category  of  processes  that  has  not  been  defined  so  far. 

3.1.1  Action  Product 

Action  product  captures  how  simultaneous  actions  (events  and  data  actions)  interact. 

An  input  event  It  represents  a  logical  condition  that  is  awaited  (at  some  time)  by  a  module. 
An  output  event  Oe  represents  the  assertion  of  a  logical  condition  at  a  particular  time  instant. 
Event  product,  written  el,e2  captures  how  two  simultaneous  events  interact. 

As  an  example,  the  rule  7e,  Oe  =>  Oe  of  figure  10  says  that  if  a  module  awaits  an  input 
condition  It  and  simultaneously  another  module  asserts  an  output  condition  Oe,  the  result 
is  as  if  Oe  is  alone  produced  at  that  moment.  One  may  ask  "what  happened  to  /e”?  The 
answer  is:  "it  got  satisfied  by  the  assertion  Oe";  in  other  words,  It  got  synchronized  with  Oe. 
This  fact,  when  taken  along  with  the  way  in  which  the  rules  of  Hiding  are  defined  later,  will 
show  us  that  the  process  that  was  awaiting  Je  will  make  progress. 

Data  actions  have  only  one  simplification  rule  defined  for  them  by  action  product:  when 
two  different  data  assertions  Ip  =  E\  and  Ip  —  E*  are  made,  the  resultant  value  on  the  port 
\p  is  defined  by  the  function  /u6(£'1,  £j).  The  lub  function  computes  the  least  upper  bound  of 
its  two  arguments  over  a  value  lattice.  (See  figure  4  for  an  example.)  A  complete  definition 
of  the  action  product  operator  is  given  in  figure  10. 

3.1.2  Definition  of  the  Transition  Relation  ^ 

In  this  section,  we  define  the  transition  relation  by  structural  induction.  Before  these  defini¬ 
tions  are  applied  to  a  realproc  or  a  vecproc,  all  the  port  and  event  names  in  their  submodules 
are  assumed  to  be  renamed  so  as  to  be  distinct.  Also  every  compound  action  used  in  a  defi¬ 
nition  is  assumed  to  have  been  reduced  to  an  irreducible  form  by  repeated  applications  of  the 
action  product  operator 

Process  STOP 

STOP  is  the  simplest  of  HOP  processes.  It  has  a  null  transition  relation;  i.e.  it  always  remains 
halted. 

A  finite  process  is  defined  to  be  one  that  will  become  STOP  in  a  finite  number  of  steps. 
A  finite  process  does  not  usually  represent  any  practically  useful  hardware  system.  Therefore 
if  PARCOMP  results  in  a  finite  process  starting  from  non-finite  processes,  there  is  room  for 
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suspicion  that  there  are  sequencing  errors  in  the  system.  When  none  of  the  input  events  in 
the  branches  of  a  CHOICE  process  P  are  synchronized,  and  when  these  input  events  are  all 
hidden,  process  P  is  turned  into  a  finite  process.  This  can  happen  (for  example)  due  to  the 
erroneous  sequencing  of  control  inputs. 

Sequential  Processes 
Action:  (co  -4  P)  -£U  P 

If  P  is  a  process,  co  -♦  P  is  a  process  that  first  performs  the  compound  action  oa  and  then 
behaves  like  P.  Sequential  Processes  are  a  special  case  of  deterministic  choices  where  there  is 
exactly  one  choice  available. 


Deterministic  Choice 
Det-choice:  (|j  co,  — ♦  Pi)  P, 

A  process  P  =j<  ca,  — »  Pit  where  i  ranges  over  an  index  set  I  is  one  that  offers  a  deter¬ 
ministic  choice  consisting  of  the  compound  actions  ca,  during  its  first  computational  step.  If 
choice  cM  is  accepted,  P  continues  to  behave  like  Pu¬ 
li  I  has  more  than  one  element,  then  there  must  be  an  input  event  e,  present  in  each  ca,. 
Since  the  e,s  govern  the  selection  of  one  of  the  alternatives  of  the  choices,  the  e,s  must  have 
pairwise  mutually  exclusive  definitions  for  their  control  encodings. 


Adding  Actions  To  Initials 

If  P  is  a  process,  cal,  P  is  a  process  which  adds  cal  to  the  initials  of  P. 
P  SUP' 


Add-to- initials: 


cal,/><— — ^  P' 


Hiding 


“Hiding  an  event  e”  is  a  shorthand  for  saying  that  both  It  and  Oe  are  hidden  from  a  process. 
Rule  Hiding-sync  considers  the  hiding  of  Oe.  Ot  is  replaced  by  Oidle. 


Hiding-sync 


P' 


Hide  e in  P 


»[ Oidlt/Oe ] 


Hide  e  in  P' 


The  notation  “ [new /old]”  is  used  to  mean  that  “new”  replaces  “old”. 

Hiding  It  from  a  process  prevents  it  from  synchronizing  on  this  event.  This  can  be  captured 
by  pruning  those  branches  of  the  synchronization  tree  that  are  labeled  by  Ie: 


Hiding-unsync 


p  p\  p  p\  e  €  cai 

(Hide  e  in  P)  (Hide  e  inP") 


Hiding  a  data  output  port  removes  data  assertions  made  on  that  port  from  the  current 
compound-action  of  the  process.  This  would  affect  those  processes  that  perform  a  data  query 
from  a  connected  port  at  the  same  time: 
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Hiding- dout 


F ' 


Hid*  p  in  P  »  Hid*  p  in  P‘ 


Hiding  a  data  input  port  causes  those  variables  that  would  have  been  bound  by  a  data 
query  on  this  port  to  remain  unbound: 


Hiding-din 


*P' 


Hid*  p  in  P  *  Hid*  p  in  P'wiih  x  fret  in  P' 


Renaming 


Processes  are  made  to  interact  with  each  other  either  via  events  or  via  data  actions  (da)  on 
ports  by  renaming  their  individual  event  and  port  names  to  common  names: 


Renaming-e 


P' 


R*nan*  e  to  el  in  P  Renan*  e  to  el  iaP' 


Renaming-port 


P  P\  da  uses  p 


Renan*  p  to  pi  in  P 


ea[pl/p] 


Rename  p  to  pi  in P' 


Parallel  Composition 


The  parallel  composition  operator  ||  models  the  process  of  realizing  a  system  by  putting 
together  several  sub-processes,  and  permitting  their  interaction  through  events  and  ports  that 
are  connected. 


Parcomp 


pislp'.  qZIq' 
(P||<?)“~  (P'\\Q') 


After  performing  parallel  composition  according  to  the  above  rule,  we  may  simplify  the 
result  by  using  the  following  rule  (if  applicable).  This  rule  captures  the  effect  of  value  com¬ 
munication: 


Value  Communication  During  Parallel  Composition 


*E).eo 


P' 


p  (!^£l,co  p'  [E/x] 


Conditionals 

HOP  processes  are  usually  defined  as  process  schemas  P[dpa],  where  for  each  value  of  dps  we 
have  one  specific  process,  dps  usually  represents  the  data  path  state  of  the  process.  We  have 
the  notion  of  conditional  processes  in  HOP  that  allows  us  to  specify  the  behavior  of  a  process 
based  on  its  dps  variable.  Thus  we  may  define  a  process  P  as: 

P(dps]  ^  if  p(dps)  then  Pl[f(dps)]  else  P2[g(dps)]. 

After  reducing  the  predicate  application  p(dps)  to  true  or  false ,  one  of  the  following  rules 
would  apply: 


Conditional 


_ Pl-^+P' 

(if  true  than  Pi  P2) 


P' 


_ P2-Z+P' _ 

(if  false  than  Pi  alaa  P2)  p1 


Recursion 

A  collection  of  one  or  more  processes  may  be  defined  recursively.  Since  only  tail-recursion  is 
allowed,  recursion  can  be  modeled  as  iteration. 

3.2  Section  Summary 

It  is  possible  to  view  HOP  as  stylized  formulae  in  Temporal  Logic.  For  instance  the  specifi¬ 
cation  in  figure  11  can  be  modeled  in  temporal  logic  as  shown  in  figure  12. 

P  [s]  <■  lei  ->  fdout  -  55  ->  P  [f(s)3 
I  Xe2,  x*?din  ->  Q  [g(t,x>] 

Figure  11:  An  Example  HOP  Specification 


P(s)  =  D((/el  3  O ((Wont  =  55)  A  C )P{f  {•)))) 

A(Je2  D  (z  =?dt'n  A  O<?(0(s>*)))) 
A(not(/el)  A  noi(lc2))  D  OERROR). 


Figure  12:  Temporal  Logic  Equivalent  of  the  Example  HOP  Specification 

In  the  Temporal  Logic  specification,  we  treat  port  names  Idin  and  ! din  as  individual 
variables.  Renaming  and  hiding  are  modeled  in  an  obvious  way.  The  effect  of  simultaneous 
data  assertions  and  queries  on  a  bus  can  be  handled  by  first  computing  the  LUB  of  the  asserted 
values  (over  the  value-lattice  of  the  data  items  asserted),  and  then  binding  this  LUB  to  the 
variables  involved  in  all  the  queries  on  this  bus. 

One  benefit  of  using  pragmatically  oriented  HDLs  that  have  a  clean  semantics  (like  HOP), 
as  opposed  to  directly  using  universal  functional/ relational  calculii,  is  simplicity.  HOP  pro¬ 
cesses  may  be  viewed  as  a  collection  of  communicating  automatons.  The  operational  semantics 
provided  in  this  section  define  the  rules  of  communication,  and  they  may  be  understood  syn¬ 
tactically.  Milner  [28]  and  Plotkin  [33]  have  extolled  the  virtues  of  this  approach. 

Another  major  benefit  of  using  HDLs  is  the  following.  Useful  ‘‘idioms" — commonly  oc¬ 
curring  patterns  in  HDL  descriptions — can  be  identified  by  trying  out  a  large  number  of 
examples.  Then  we  can  identify  a  subset  of  Temporal  Logic  (or  another  formalism)  that 
matches  these  idioms.  The  advantages  of  identifying  such  subsets  of  ( inherently  undecidable) 
theories  is  obvious — we  can  make  a  focussed  attack  on  the  problem  of  verification  and  testing 
of  hardware. 
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4  Illustration  of  PARCOMP 

4.1  What  Exactly  Does  PARCOMP  Do? 

PARCOMP  takes  as  input  a  realproc  or  a  vecproc  and  produces  as  output  an  absproc.  It  works 
by  symbolically  simulating  all  possible  interactions  between  the  subprocesses  of  a  realproc  or 
vecproc  PACOMP  implements  the  operational  rules  of  HOP  presented  in  section  3. 

The  absproc  inferred  by  PARCOMP  captures,  via  symbolic  expressions,  the  behavior  of 
the  realproc  or  vecproc  for  all  possible  starting  states  of  the  submodules,  and  for  all  external 
inputs.  The  text  of  the  inferred  absproc  can  be  manually  studied  to  see  if  the  system  behaves 
as  understood  by  the  designer.  Thus,  PARCOMP  greatly  facilitates  the  understanding  of  the 
collective  behavior  of  a  collection  of  synchronous  systems. 

In  addition,  PARCOMP  throws  away  all  of  the  unused  capabilities  of  a  system.  Consider  a 
system  built  using  three  modules  A,  B,  and  C,  where  C  is  the  controller  for  A  and  B.  Though 
A  and  B  may  individually  support  (say)  5  operations  each,  C  may  actually  use  only  (say)  2 
each  of  their  operations.  In  addition,  of  these  2  operations  used,  C  may  sequence  them  only 
in  a  small  number  of  ways— out  of  the  myriads  of  possible  ways  they  may  be  sequenced.  In 
other  words,  C  implements  only  some  of  the  astronomically  large  number  of  possible  micro¬ 
routines.  Such  under-utilization  of  system  capabilities  is  the  rule,  rather  than  the  exception, 
in  hardware.  PARCOMP  “distills  out”  only  the  used  modes  of  behavior  by  capitalizing  on  the 
event  hiding  information  supplied  by  the  designer.  Thus,  the  behavioral  descriptions  inferred 
by  PARCOMP  contain  just  the  right  amount  of  information,  and  nothing  more. 

In  addition  to  distilling  away  unutilized  modes  of  behavior,  the  Hiding-unsync  rule  reduces 
the  time  complexity  of  PARCOMP.  The  worst-case  time  complexity  of  PARCOMP  is  propor¬ 
tional  to  the  number  of  control  state  tuples  actually  generated.  By  pruning  away  as  many 
control  state  tuples  as  early  as  possible,  these  control  state  tuples  as  well  as  their  successors 
are  never  visited. 

Finally,  PARCOMP  can  be  used  to  save  the  time  of  simulation;  we  can  perform  a  “pre 
simulation”  of  the  tester  and  the  testee  using  PARCOMP,  and  run  the  resultant  process. 
These  computational-effort  saving  measures  are  believed  to  be  new. 

4.2  Illustration  of  PARCOMP  on  the  Stack 

Given  the  above  stack  realproc  specification  and  given  the  specifications  for  CTR  and  SCTL 
shown  in  figure  7,  we  can  use  PARCOMP  to  infer  the  equivalent  absproc  specification  STACK 
shown  in  figure  13.  (Only  the  PROTOCOL  section  of  the  inferred  process  is  shown.)  This 
description  was  obtained  automatically,  using  our  implementation  of  PARCOMP.  Inferring  the 
behavior  of  the  stack  takes  less  than  ten  seconds  of  elapsed  time  running  on  an  HP-Bobcat 
running  compiled  HP  Common  Lisp. 

The  inferred  PROTOCOL  specification  asserts  that  the  STACK  system  offers  a  choice  of 
events  Ireset,  Ipush,  Itop,  Ipop,  and  Inop. 

Let  us  study  Itop.  After  asserting  this  event,  the  external  world  (say,  the  “tester  process” 
of  the  stack)  has  to  idle  for  one  tick.  No  event  is  entertained  by  the  stack  (signified  by  the 
absence  of  any  input  events  following  Itop),  as  it  is  internally  busy.  During  the  second  tick,  it 
asserts  the  data  value  read(ms,ca)  on  the  »dout  port.  This  symbolic  expression  confirms  that 
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PROTOCOL 
STACK  [ca.na]  <■ 

Iruit  ->  dl  -  Tcdi  ->  STACK  [di.na] 

I  I  push  ->  Oidl*  •>  Td"?din  ->  STACK  CaddlCca),  writ* (■*, add l(ca)  ,*d)] 

I  Xtop  ->  Oidl*  ->  tdout*r*ad(aa ,ca)  ->  STACK  [ca,na] 

I  I  pop  ->  Oidl*  ->  STACK  CaubKca),  ns] 

I  I nop  ->  STACK  [cs .ns] 


lanoo 


Imt  ,mp  (a)] 


Figure  13:  Abaproc  Automatically  Inferred  from  atkreal  using  PARCOMP 
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the  stack  would  output  the  correct  result  on  port  !dout  following  the  top  command.  Finally, 
the  STACK  [cs  .its]  process  continues  to  behave  like  STACK  [cs,  ns]  itself,  meaning  that  the 
STACK  process  did  not  suffer  any  state  changes. 

Let  us  study  the  push  operation.  The  external  world  is  expected  to  supply  the  item 
to  be  pushed  two  ticks  after  it  applied  the  Opush  trigger  that  matched  with  the  Ipush 
event.  If  this  value  were  vd,  then  the  future  behavior  of  STACK  would  be  like  that  of 
STACK(addl(cs),write(ms,addl(c8),vc )].  This  symbolic  expression  shows  that  the  push  op¬ 
eration  was  implemented  correctly.  This  is  because  the  counter  state  has  advanced  from  cs 
to  addl(cs),  and  the  memory  state  has  advanced  from  as  to  vrite(u,addl(ca)  ,vd).  In¬ 
formally,  the  stack  pointer  was  incremented,  and  the  memory  location  pointed  to  by  the  new 
stack  pointer  was  written  with  vd. 

The  other  operations  are  similarly  correct.  (Note:  While  doing  the  reset,  the  initial  stack 
pointer  value  has  to  be  fed  from  outside  via  ?cdi.) 

4.3  How  Does  PARCOMP  Work? 

4.3.1  Lockstep  Cross-product  Automaton 

Our  explanation  of  PARCOMP  would  be  greatly  facilitated  by  introducing  the  concept  of 
lockstep  cross-product  automatons.  Given  two  DFAs  A  and  B,  a  lockstep  cross-product  au¬ 
tomaton  (LCA)  of  A  and  B,  written  lca(A,B),  can  be  obtained  from  A  and  B  by  the  following 
algorithm: 

(Basis  clause):  If  Ao  is  the  initial  state  of  A,  and  Bo  is  the  initial  state  of  B,  then  the 
pair  <  Ao,B0  >  is  in  lca(A,B). 

(Inductive  clause):  If  state  <  B,  >  is  in  lca(A,  B ),  and  there  is  a  directed  edge 
going  from  Ai  to  a  state  A:  in  A,  (and  likewise  F,:  is  a  directed  edge  going  from  state  B, 
to  a  state  Bj  in  B),  then  <  Aj,  Bj  >  is  in  lca(A,  B).  Further,  the  edge  EFX}  is  introduced 
in  lca(Ax  B)  going  from  <  AXXBX  >  to  <  AixBj  >. 

(Closure  clause):  There  is  no  other  state  or  edge  in  lca(AxB). 

Example:  Consider  the  state  diagrams  in  figure  14  to  be  DFAs,  with  state  0  being  the  starting 
states  of  A  and  B.  Then,  lca(A,  B)  contains  all  the  25  states  in  the  cross-product  of  A  and 
B.  On  the  other  hand  if  the  self- loop  at  state  0  of  process  B  were  to  be  absent,  then  it  will 
contain  only  the  five  states  00,  11,  22,  33,  and  44.  The  edges  in  lca{A,B)  would  then  be: 
00  — »  11,  11  — »  22,  22  —*  33,  33  — *  44,  44  — ♦  00.  Thus,  we  conclude  that  the  number  of  states 
in  lca(Ax  B)  is  less  than  or  equal  to  the  product  of  the  number  of  individual  control  states  in 
A  and  B. 

PARCOMP  works  by  attempting  to  create  the  LCA.  However,  as  we  show  below,  it  actually 
doesn't  create  the  entire  LCA  graph— often  it  creates  only  a  small  portion  of  the  LCA  graph. 
In  this  section,  we  discuss  only  the  version  of  PARCOMP  that  doesn’t  use  the  cond  construct. 
The  cond  construct  is  considered  in  section  A.l. 

4.3.2  An  Illustrative  Example 
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Figure  14:  Processes  A,  B,  and  AB 
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Figure  15:  The  Realization  of  the  System  AB 

We  illustrate  PARCOMP  on  one  example  that  has  been  specially  constructed  to  involve  most 
of  the  interesting  cases  that  arise  during  PARCOMP.  (A  rigorous  specification  of  PARCOMP 
is  presented  in  section  A.l.) 

The  Structural  Details 

Two  processes  A  and  B  are  connected  to  form  a  system  called  AB,  as  shown  in  figure  15.  The 
Oel  event  of  A  is  unconnected  as  well  as  hidden;  hence  it  is  effectively  ignored  throughout. 
Event  Oe  of  A  is  conneced  to  event  le  of  B,  and  hence  whenever  le  is  offered  by  B  and  Oe  is 
asserted  by  A,  the  events  would  synchronize.  This  event  is  also  exported  as  event  Oer  of  AB. 
Thus  whenever  Oe  is  asserted  by  A,  event  Oer  would  be  seen  asserted  outside  AB. 

Process  A  has  a  data  port  !do  connected  to  port  ?di  of  B.  Since  this  connection  is  hidden 
within  AB,  the  data  assertions  on  !do  will  not  be  visible  outside  AB.  A  also  has  an  output 
port  !do2  that  is  connected  to  input  port  ?di  of  A,  output  port  Ido  of  B,  and  output  port  Ido 
of  AB.  The  effects  of  these  connections  will  be  discussed  momentarily.  B  has  an  input  port 
?hid  that  is  connected  nowhere;  the  effect  of  querying  through  this  port  will  be  of  interest. 
Finally,  B  has  an  input  port  ?«xp  that  is  exposed  outside  AB;  the  effect  of  B’s  query  on  this 
port  will  also  be  of  interest. 

The  Behavioral  Details 

The  above  structural  connections  show  the  potentials  for  interaction  through  events  and  data 
ports.  Whether  these  potentials  are  actually  used  would  depend  upon  the  protocol  specifica¬ 
tions  of  A  and  B. 

Figure  14  depicts  the  PROTOCOL  sections  of  processes  A  and  B.  At  time  0,  process  A  is 
in  control  state  0  and  has  data  path  state  [as] .  (Data  path  states  are  always  sequences  of 
one  or  more  items,  and  we  write  them  within  square  brackets,  to  mimic  the  syntax  used  in  the 
textual  version  of  the  HOP  specification.)  While  in  control  state  0,  A  keeps  an  output  event 
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0«  asserted.  It  also  asserts  the  data  value  !do»F(as)  so  long  as  it  stays  in  control  state  0.  It 
instantaneously  jumps  to  state  1,  when  time  instant  1  arrives.  In  control  state  1,  it  asserts  a 
data  item,  and  also  queries  port  ?di  to  obtain  a  value  for  a  local  variable  y.  Until  it  is  bound 
again,  the  value  of  variable  y  will  represent  the  value  on  port  ?di  at  time  1.  Process  A  then 
moves  to  control  state  2.  Further  behavior  of  A  can  be  similarly  understood.  We  indicate 
the  state  0  of  A  using  a  darker  circle  because  it  corresponds  to  the  explicitly  named  process 
“A [as]”  in  the  textual  description  of  A. 

Let  us  consider  B.  It  offers  a  deterministic  choice  (as  explained  in  section  3)  between  events 
lei  and  le  in  state  0.  The  former  transition  will  be  taken  if  event  lei  is  asserted  (from  outside 
B),  end  event  le  is  not  asserted.  The  latter  transition  will  be  taken  if  event  le  is  asserted, 
and  event  lei  is  not  asserted.  (The  events  guarding  the  “arms”  of  a  deterministic  choice  are 
mutually  exclusive,  by  definition.)  If  Is  is  asserted,  the  data  query  x*?di  will  be  made.  After 
this  query,  B  goes  to  control  state  1.  From  control  state  1,  it  goes  to  control  state  2,  and 
its  data  path  state  changes  to  [bs,  x].  State  2  of  B  is  shown  using  a  dark  circle  because  it 
corresponds  to  the  explicitly  named  process  Bl  [bis ,t] .  Note  that  we  show  the  “next  data 
path  state”  only  if  it  changes.  B  starts  from  control  state  2  in  data  path  state  [bis  ,t] .  This 
pair  is  bound  to  [bs  ,x]  by  virtue  of  the  data  path  state  change  shown  along  the  arc  1  — »  2. 

If  processes  A  and  B  are  coupled  using  the  structure  shown  in  figure  15,  and  allowed  to  run 
starting  them  both  in  state  0,  their  behavior,  as  seen  from  outside  AB,  will  be  that  of  process 
AB  in  figure  14.  This  behavior  was  automatically  deduced  using  the  PARCOMP  procedure. 

Operational  Rules  Invoked  in  Deducing  Process  AB 

The  rules  Renaming-e  and  Renaming-port  of  section  3  are  used  to  model  connections  between 
ports  and  events.  (In  our  narration  below,  we  will  perform  these  renamings  “as  and  when 
needed”  during  explanation.)  Since  A  and  B  interact,  we  invoke  the  rules  Parcomp  and  Value 
Communication  During  Parallel  Composition.  Finally  we  invoke  the  rules  of  hiding,  to  take 
into  account  the  hidden  events  and  ports. 

We  now  discuss  some  specific  instances  of  these  rules,  with  respect  to  figure  14. 

•  PARCOMP  can  be  thought  of  as  a  nested  iterative  procedure  where  the  outer  loop 
attempts  to  generate  the  LCA.  The  inner  loop  performs  action  products  of  events  and 
data  queries/assertions,  obtaining  simplified  events  and  data  queries/assertions.  These 
are  used  to  annotate  the  edges  of  the  LCA,  thus  obtaining  the  inferred  absproc. 

To  clarify  this,  consider  the  move  of  B  from  0  to  0,  and  of  A  from  0  to  1.  Wre  obtain  the 
LCA  edge  00  -*  10.  Label  this  edge  with  the  set  of  actions  obtained  from  the  0  -*  1 
edge  of  A  and  the  0  -+  0  edge  of  B. 

(Convention:  We  show  these  actions  prefixed  by  “A:”  if  they  are  caused  by  A,  and  “B:” 
if  caused  by  B.  If  caused  by  A  and  B  collectively,  we  prefix  it  by  “AB:”.) 

This  compound  action  is: 

B  :  Iel,  A  :  0e,  A  :  Ido  «  F(as) - (1) 

The  other  edge  in  the  LCA  is  00  — ►  11,  and  is  labeled  by 

A  :  Oe,  B  :  le,  A  :!do  =  F(as),  B  :  x  =?di - (2) 
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•  Consider  equation  (1).  This  equation  is  irreducible  under  the  action  product  operation 
(the  rules  in  figure  10).  Further,  it  contains  the  event  lei  that  is  u asynchronized  and 
hidden.  This  represents  a  possible  move  of  B  that  will  never  materialize.  So  we  can 
invoke  the  rule  Hiding- unsync,  and  prune  away  this  possibility.  Thus,  we  delete  the 
00  — » 10  edge  from  the  lca(A,B). 

This  step  accounts  for  the  practical  efficiency  of  PARCOMP.  In  the  current  example, 
thu  one  pruning  step  prevents  the  generation  of  the  following  control  state  pairs  of  AB: 
20,  30,  40.  This  is  because  20,  30,  and  40  are  all  successors  of  10,  in  the  LCA  of  AB. 

•  Consider  equation  (2).  It  is  reducible  through  equation  2  of  figure  10.  It  reduces  to 

AB  :  Oe,  A  :!do  *  F(as),  B  :  x  *=?di - (3) 

This  fact  represents  that  Ze  synchronizes  with  0e. 

Ports  !do  and  ?di  are  connected.  Since  connections  are  modeled  via  renaming  to  a  com¬ 
mon  name,  let  us  rename  ?di  to  ?do.  Now  we  can  invoke  the  rule  value  communication 
during  parallel  composition,  and  simplify  (3)  to: 


AB  :  Oe,  A£:!do  =  F(as) - (4) 

and  also  generate  the  substitution  [lr(as)/i]  to  be  applied  to  the  “rest  of  the  parallel 
composition".  This  shows  that  the  variable  x  of  B  would  be  bound  to  F(gs),  thus 
showing  that  a  value  communication  has  occurred. 

•  Equation  (3)  contains  Oe  that  is  not  hidden — it  connects  to  the  event  Oer  of  AB.  Thus 
we  see  Oer  being  asserted  by  AB  during  the  first  transition.  However,  port  !do  is  hidden, 
and  so  we  do  not  see  this  data  assertion  being  asserted  by  AB.  The  value  communication 
does  happen,  albeit  internally. 

•  PARCOMP  proceeds  thus,  and  re-encounters  state  00.  It  nowr  has  to  compute  PAR¬ 
COMP  of  A  and  B  which  are  (respectively)  in  data  path  states  NS-A( . . . )  and  NS-B  (...). 
However  we  have  already  computed  the  PARCOMP  of  A  and  B  for  data  path  states  (re¬ 
spectively)  as  and  bs — these  are  free  variables,  and  hence  more  general  than  NS-A( . . . ) 
and  NS~B( . . .).  Hence  nothing  is  to  be  gained  by  doing  PARCOMP  again,  and  so  the 
algorithm  stops. 

The  other  interesting  things  that  happen  along  the  way  are: 

-  The  data  assertion  !dot»lub(G(x)  .as)  is  produced  by  AB  at  time  1,  as  a  result 
of  the  “collision"  of  the  data  assertions  fdo2>as  by  A  and  !do«G(x)  by  B.  The 
“resultant"  assertion  is  computed  using  the  action  product  rule  3  of  figure  10. 

-  The  assertion  !dor*J(F(as)  ,H(lub(G(F(as))  ,  as)))  made  at  time  3  is  explained 
thus:  there  is  an  assertion  made  by  B  at  time  3.  This  assertion  is  J(t  ,z).  However 
by  now’,  t  and  z  have  accumulated  value  bindings,  and  these  value  bindings  are 
substituted  in.  Thus  we  see  that  the  behavior  of  AB  represents  the  effects  of  value 
communications  between  A  and  B  in  a  closed  form. 
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Figure  16:  Inferred  Behavior  of  the  Stack  using  an  Erroneous  SCTL 

-  A  final  point  of  interest  is  the  occurrence  of  the  term  UB  in  the  next  data  path 
expression  when  going  from  state  44  of  AB  to  state  00.  UB  stands  for  ‘‘unbound”, 
and  results  from  the  query  that  B  performed  on  its  hidden  port  ?hid.  This  is 
obtained  formally  by  invoking  the  rule  Hiding-din.  So  long  as  this  UB  value  is  never 
“used”,  the  system  can  compute  along  safely.  An  example  would  be  this:  if  B  were 
an  OR  gate  and  if  one  of  its  inputs  is  already  1,  then  the  other  input  could  be  UB. 
(UB  will  be  bound  to  HOP’s  HIZ  value  “Z”,  or  to  boolean  False  (“F”  in  HOP), 
depending  on  the  actual  IC  technology  used.) 

5  Experiments  with  PARCOMP 

In  this  section  we  present  various  experiments  that  we  have  conducted  using  PARCOMP. 

5.1  Introducing  Protocol  Errors 

We  deliberately  introduced  mistakes  into  the  stack  controller  and  wanted  to  see  if  PARCOMP 
could  detect  these  errors.  Here  is  a  specific  experiment:  take  the  process  SCTL  defined  in 
figure  7,  and  delete  the  Oread  event  that  is  generated  after  synchronizing  on  event  Itop. 
PARCOMP  is  able  to  detect  this  as  an  error. 

This  is  possible  because  of  the  following  reason.  By  omitting  Oread,  the  SCTL  process 
does  not  generate  any  of  the  choices  that  MEM  offers  at  that  moment.  Thus  the  behavior  of 
MEM  beyond  this  point  is  not  defined.  Hence  the  behavior  of  the  stack  beyond  this  point  is 
not  defined. 

The  results  of  PARCOMP  with  this  erroneous  SCTL  are  shown  in  figure  16.  The  inferred 
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Figure  17:  The  Pipelined  Stack  Controller 

Absproc  has  a  transition  from  state  000  to  state  STOP,  which  is  a  dead-end.  A  STOP  control 
state  in  a  process  is  indicative  of  a  design  error,  because  a  hardware  system's  behavior  must 
be  defined  for  every  time  instant.  Thus  when  a  STOP  state  is  generated  during  PARCOMP,  it 
issues  a  warning  to  the  user.  This  feature  of  PARCOMP  can  help  ensure  that  timing  protocols 
are  mutually  compatible.  Much  like  in  type-checking,  the  assumption  is  that  in  a  majority 
of  cases  only  one  process  would  be  “wrong’’  relative  to  the  other;  that  is,  we  won’t  make 
“compatible  mistakes”  in  two  systems,  at  the  same  time. 

However  note  that  not  all  timing  errors  will  be  caught  in  the  above  manner.  It  should  be 
clear  that  certain  errors  will  not  lead  to  any  dead-end  control  states,  but  would  nevertheless 
give  rise  to  erroneous  modes  of  behavior. 

5.2  Pipelining  the  Stack 

The  inferred  behavior  of  the  Stack  presented  in  figure  13  shows  that  it  takes  3  ticks  to  complete 
the  push  operation.  Probing  the  reasons  for  this,  we  see  that  SCTL  is  the  source  of  this  time 
wastage.  It  accepts  Zpush  during  the  first  tick,  does  Oup  during  the  second,  and  Ovrite  during 
the  third;  then  only  goes  back  to  state  0. 

We  can  overlap  the  last  Ovrite  operation  with  the  awaiting  of  the  next  command  on  the 
stack.  Doing  so,  we  would  have  pipelined  the  stack.  The  controller  used  for  this  purpose 
is  PCTL,  shown  in  figure  17.  After  accepting  Ipush  and  performing  Oup,  PCTL  goes  into 
control  state  3.  Here  while  it  awaits  the  next  stack  operation,  it  performs  the  deferred  Ovrite 
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Figure  19:  A  Tester  Process  for  the  Pipelined  Stack 


operation. 

Using  PCTL  and  the  same  old  MEM  and  CTR,  PARCOMP  infers  the  behavior  shown  in 
figure  18.  This  behavioral  description  shows  all  the  modes  of  behavior  of  the  stack.  We  will 
study  some  of  these  modes  in  the  next  section. 

5.3  Testing  the  Pipelined  Stack,  aided  by  PARCOMP 

How  do  we  know  that  the  pipelined  stack  is  correct?  One  way  is  to  formally  verify  it  against 
a  requirements  specification.  We  do  not  take  this  approach  in  this  paper. 

Let  us  instead  test  the  pipelined  stack,  to  gain  some  confidence  in  its  correctness.  Let  us 
describe  a  tester  process  in  HOP  that  would  apply  the  following  sequence  of  operations: 

reset(stack);  push(stock,  1);  push(stack,2);  pop(siack);  top(stack). 

The  expected  result  of  this  test  is  1. 

In  order  to  test  the  stack,  we  should  apply  the  above  sequence  of  commands  observing 
proper  timings  for  command  invocations,  data  assertions  from  outside,  and  the  data  query  for 
the  result  of  the  top  operation.  It  is  our  understanding  of  the  timing  ms  well  ms  functionality 
of  the  stack  that  we  wish  to  confirm  through  testing.  The  tester  so  constructed  is  shown  in 
figure  19. 

We  can  compose  the  tester  and  the  “testee”  (the  pipelined  stack)  using  PARCOMP,  and 
thus  obtain  a  single  process  that  embodies  all  observable  aspects  of  the  collective  behavior 
of  the  tester+testee.  We  can  then  run  this  single  resultant  process.  The  resultant  process  is 
shown  in  figure  20.  This  approach  has  many  practical  advantages,  and  they  are  discussed  in 
the  following  subsections. 
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Figure  20:  Composition  of  the  Tester  and  the  Testee  (the  pipelined  Stack) 
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5.5.1  Detecting  Timing  Errors  in  Tester  Processes  Statically 

PARCOMP  can  reveal  certain  timing  errors  in  the  tester,  relative  to  the  testee.  In  these  cases, 
wasteful  simulation  needn't  be  performed,  and  instead  the  error  can  be  corrected. 

5.5.2  Obtaining  Symbolic  Simulation  Results  Without  Simulation 

As  figure  20  shows,  the  inferred  process  reveals  (approximately)  how  the  simulation  would 
proceed.  For  instance,  it  tells  us  that  the  final  result  delivered  by  the  top  operation  is: 

(result  ■ 

(READ 

(WRITE  (WRITE  NS  (ADD1  0)  1)  (ADD1  (ADD1  0))  2) 

(SUB1  (ADD1  (ADD1  0))) 

) 

In  this  simple  example,  we  can  readily  tell  that  this  answer  is  correct;  for,  we  can  apply  simple 
algebraic  rules  of  ADDl  and  SUB1,  to  simplify  this  data  assertion  to: 

(result  * 

(READ  (WRITE  (WRITE  MS  1  1)  2  2)  1) 

This  can  further  be  simplified  to  1,  using  the  following  algebraic  axiom  of  ordinary  read- write 
memories: 

read(write(m,a,  d),  a)  —  d. 

And  1  was  indeed  our  expected  answer. 

This  opens  up  the  following  attractive  path  towards  speeding  up  functional  simulation: 

1.  Build  an  algebraic  expression  simplifier  as  a  part  of  the  abstract  data  type  library. 

2.  Obtain  the  “tester+testee”  process  thru  PARCOMP. 

3.  Extract  all  the  the  next  data-path  state  and  data  assertion  expressions  present  in  this 
tester+testee.  Simplify  them  using  the  expression  simplifier. 

4.  Plug  these  simplified  expressions  back  into  the  tester+testee. 

5.  Run  detailed  functional  simulation  on  this  simplified  tester+testee. 

We  also  have  developed  the  prototype  of  a  compiled  simulator  that  compiles  “tester+testee” 
processes  into  procedural  code.  This  simulator  is  called  the  CAPS  (Compiled  AbsProc  Sim¬ 
ulator).  (Note:  Some  of  the  above  ideas  may  be  found  in  [15]  also.) 

5.3.3  Building  Partial  Testers 

Suppose  we  want  to  supply  certain  test  stimulii  “automatically”  from  the  tester  process  and 
some  other  test  stimulii  interactively  from  the  keyboard.  This  can  be  very  easily  done  in  our 
present  approach.  For  example,  let  us  assume  that  the  user  wants  to  have  control  over  the  first 
data  item  being  pushed  on  the  stack.  He/she  would  simply  leave  out  the  data  assertion  !  dot«l 
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from  figure  19.  Running  PARCOMP  on  this  “tester+testee"  would  result  in  an  “unsatisfied 
but  un- hidden*  data  query  at  time  4.  When  we  run  CAPS  on  such  an  absproc,  the  unsatisfied 
data  query  is  turned  into  a  query  from  the  keyboard. 

Thus  users  may  selectively  add  or  take  away  events  and  data  assertions  from  the  tester 
process.  Thus,  a  range  of  testers  are  possible.  At  one  extreme,  the  tester  does  every  data 
assertion  and  query,  and  so  the  CAPS  simulation  will  run  on  its  own,  without  user  intervention. 
At  the  other  extreme,  the  tester  would  do  nothing,  and  the  CAPS  simulator  would  interrogate 
the  user  for  every  event  and  data  input.  This  eras  a  pleasant  and  serendipitous  discovery. 

5.3.4  Interpreted  Realproc  Simulator 

Sometimes  it  may  be  felt  necessary  to  simulate  a  collection  of  processes  without  doing  PAR¬ 
COMP.  This  need  can  arise,  for  example,  during  the  very  early  stages  of  a  design  where 
(i)  users  may  want  to  simulate  a  proper  subset  of  the  subprocesses;  (ii)  users  may  want  to 
get  detailed  information  about  the  innards  of  a  system.  To  support  this  need,  we  have  devel¬ 
oped  a  run-time  version  of  PARCOMP  that  is  embodied  in  an  Realproc  Interpreted  Process 
Simulator  (RIPS). 

In  the  RIPS  simulator,  the  tester  and  testee  are  run  concurrently,  and  the  action  products 
are  computed  at  run-time.  RIPS  is  relatively  more  inefficient  than  CAPS;  however,  RIPS 
allows  many  flexible  interactions  not  possible  with  CAPS.  For  example,  after  a  few  simulation 
steps,  we  can  selectively  ignore  a  subset  of  the  modules,  and  carry  the  other  modules  forwards 
in  simulation.  Or,  we  can  add  an  extra  process  after  a  few  steps. 

5.3.5  The  use  of  Probe  Processes 

Logic  state  analyzers  are  widely  used  to  debug  digital  systems.  In  HOP,  we  can  simulate  logic 
state  analyzers,  by  constructing  probe  processes. 

A  probe  process  is  constructed  by  specifying  along  its  transitions  a  trace  of  the  sequence 
of  events  and  data  assertions  of  interest.  Such  a  trace  is  similar  to  a  “trigger"  specification  of 
a  logic  state  analyzer.  We  can  then  PARCOMP  the  probe  process  with  the  submodules  of  a 
system,  and  then  simulate  the  system. 

Here  is  a  probe  process  that  can  be  used  with  the  pipelined  stack: 

PROBE  <■  I write  ">  I write  ">  Iwrite  *>  Iread  ->  ‘probeout  »  '‘Success" 

The  operator  ">  is  an  abbreviation  for  “busy  wait  until  the  following  input  event*.  This 
derived  operator  is  available  in  HOP,  and  can  be  expressed  in  terms  of  ->. 

If  this  probe  process  were  to  be  composed  with  the  pipelined  stack  and  tested  using  fig¬ 
ure  19,  it  will  sense  whether  the  memory  is  being  subject  to  three  writes  and  one  read.  If  so  it 
will  print '  'Success ' '  on  the  !  probe  out  port.  For  the  command  sequence  push;  push;  pop;  top 
applied  by  our  tester,  this  trace  must  manifest  on  the  memory  subprocess.  Probe  processes 
may,  after  sensing  the  trigger  condition,  start  acquiring  data,  and  may  even  act  like  tester 
processes  by  supplying  test  patterns. 
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5.3.6  Checking  for  Representation  Invariants 

Probe  processes  may  be  used  for  flagging  the  violation  of  of  representation  invariants  during 
the  course  of  operation  of  a  module.  Representation  invariants  [23]  are  predicates  that  describe 
the  consistent  internal  states  of  a  module.  As  an  example,  consider  a  simple  associative 
memory  (AM)  with  4  locations.  A  representation  invariant  found  in  most  AMs  is:  “AM  never 
contains  duplicate  entries”.  Stated  formally, 

Vx  unary  (assoc  jtrch(  AM ,  x)). 

This  says  that  d,  the  result  of  doing  an  associative  search,  is  always  a  unary  quantity.  If  the 
unary  pattern  is  *0000”,  it  indicates  that  the  search  “missed”.  If  the  pattern  is  *0010”,  it 
indicates  that  there  was  a  hit  at  location  3.  If  pattern  is  *0101”,  it  indicates  that  x  was  found 
in  location  0  and  3;  this  is  erroneous.  A  probe  process  to  detect  this  condition  is: 

H0DUP  <■  I search,  x«?srchdata  ->  if(unary(x),  M0DUP,  ERROR) 

ERROR  <*  Iprobeout  ■  "Error"  ->  STOP 

The  probe  process  N0DUP  samples  the  Isearch  event  that  triggers  the  associative  search.  It 
samples  the  search's  result,  x,  also.  Then  if  x  is  found  to  be  unary,  it  goes  back  to  behave  like 
N0DUP.  Else  it  behaves  like  the  ERROR  process. 

This  technique  has  one  limitation:  quite  often,  the  entire  internal  state  of  a  module  is  not 
observable  through  its  output  ports.  To  overcome  this  limitation,  we  are  investigating  the 
use  of  daemons — data  driven  procedures — that  can  directly  monitor  the  ADT  object  states. 
Some  details  appear  in  appendix  A.2. 


6  A  Divide-and-conquer  PARCOMP,  PARCOMP-DC 

This  section  shows  how  we  can  often  reduce  the  run-time  of  PARCOMP  by  exploiting  the  fact 
that  it  is  commutative  and  associative. 

Consider  the  array  A  shown  in  figure  21.  It  consists  of  a  collection  of  modules  M  con¬ 
nected  in  a  regular  interconnection  pattern.  For  simplicity  of  explanation,  assume  a  nearest- 
neighbor  connection  that  is  regular  in  both  the  dimensions.  Consider  the  problem  of  comput¬ 
ing  PARCOMP(A)\  i.e.  the  composition  of  all  the  Ms  constituting  A.  Since  PARCOMP 
is  both  commutative  and  associative,  we  can  split  A  into  two  halves,  say  At  standing  for  “the 
top  of  A”  and  AB,  standing  for  *the  bottom  of  A”,  and  assert: 

PARCOMP(A)  =  PARCOMP(  PARCOMP(AT),  PARCOMP(AB ) ). 

Since  Aj  and  AB  differ  only  in  the  names  of  their  external  ports,  we  need  compute  only 
P ARCOMP(Aj).  PARC OMP(AB)  can  be  obtained  from  this,  by  renaming  the  ports  of 
Aj  to  the  corresponding  ports  of  AB. 

This  division  process  can  be  carried  down  to  the  leaf  cells,  as  depicted  in  figure  21. 

PARCOMP-DC  is  often  more  efficient  than  PARCOMP.  Let  us  make  an  approximate  cost 
analysis. 

As  discussed  in  section  4.3.1,  the  worst-case  time  complexity  of  PARCOMP  is  proportional 
to  the  cross-product  of  the  number  of  control  states  in  each  of  the  processes,  assuming  that  the 
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Each  cell  is  'M' 


via  copying  and  renaming. 


Figure  21:  Divide  and  Conquer  PARCOMP 
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number  of  events  end  data  assertions  on  every  transition  are  bounded  by  a  constant.  Suppose 
for  simplicity  that  array  A  is  square,  and  has  N  modules  of  type  M ,  M  has  C  control  states 
in  it,  and  that  N  be  a  power  of  2.  Then 

eost^arcornp{A)  =  0(CN). 

Suppose  that  the  modules  formed  during  the  division  process  of  PARCOMP-DC  are  M , 

At  Li  At,  A.  Let  ncs(M)  denote  the  number  of  control  states  in  a  module  M.  Further  let 
Cxopying  denote  the  cost  of  copying  the  process  descriptions  (see  figure  21).  Then 

costjxircompjic(A )  *=  0(ncs(M )2  +  ...  +  ncs(Ajz)s  +  ncs(Aj-)a  +  nes(A)3  +  C  copying). 

The  above  sum  has  logt(N)  terms.  Let  D  be  the  root  mean  square  (RMS)  value  of  the 
number  of  control  states  in  M, ...,  Atl,  At,  A.  Let  the  cost  of  copying  and  applying  renamings 
to  a  process  description  not  exceed  the  number  of  control  states  in  it. 

Then, 


costj>arcompjlc(A)  =  0(log2(Ar)  x  (D2  +  D2))  *  0(log2(N)  x  D 2). 

Firstly  we  note  that  D  does  not  tend  to  increase  as  the  size  of  the  modules  grow.  This  is 
a  fact  of  practical  systems  because  when  designing  a  module  using  several  submodules,  only 
very  few  of  the  astronomically  large  number  of  sequences  of  the  submodule  operations  are 
actually  used.  Hence  the  number  of  control  states  in  a  module  is  often  vastly  smaller  than 
what  it  could  be.  (Consider  for  example  the  total  number  of  possible  microprograms  for  a 
typical  datapath  .vs.  the  number  of  microroutines  that  are  actually  ever  used!)  Thus  if  D  is 
close  to  C  and  if  M  is  large,  then  there  is  a  significant  payoff  by  using  PARCOMP-DC. 

In  conclusion,  the  following  additional  avenues  of  research  are  available  for  handling  geo¬ 
metrically  regular,  (but  perhaps  computationally  irregular — or  arhythmic)  arrays: 

•  Perform  PARCOMP  of  two  modules  of  the  array; 

•  Study  the  inferred  behavior  and  see  if  it  is  verifiable  manually  or  through  exhaustive 
simulation. 

•  The  behavior  inferred  by  PARCOMP  (or  PARCOMP-DC)  will  have  complex  if-then-else 
functions.  Construct  tabular  functions  corresponding  to  these. 

•  Use  these  tabular  functions  for  efficient  simulation. 

•  Try  to  perform  formal  verification  of  the  whole  array  by  setting  up  an  induction. 

7  Summary  of  the  Paper 

We  presented  a  language  “Hardware  viewed  as  Objects  and  Processes"  (HOP)  for  specifying 
the  structure,  behavior,  and  timing  of  hardware  systems.  HOP  embodies  a  simple  process 
model  for  lock-step  synchronous  processes. 

We  presented  the  communication  primitives  of  HOP,  illustrated  HOP  through  several  ex¬ 
amples,  and  then  presented  its  operational  semantics.  Several  design  automation  algorithms — 
especially  PARCOMP — were  then  examined  in  detail. 
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The  results  presented  herein  were  obtained  from  our  implementation  of  the  HOP  design 
system.  Section  A.2  presents  an  overview  of  this  system.  It  has  a  working  prototype,  currently 
written  in  Common  Lisp  and  FROBS  [31].  Though  we  have  taken  simple  examples  in  this 
paper,  we  have  worked  out  some  larger  examples  as  well.  Some  of  these  hardware  units  are 
discussed  in  [12];  many  are  yet  to  be  published.  Links  to  VLSI  design  are  briefly  described  in 
section  A.2. 
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A  Appendix 

A.l  A  Specification  of  PARCOMP 

[Input;  |  As  expression  Hide  HS  in  ||  {Pi[Xi)> ...»  Cj[Xj],...}  for  *  €  j  6 

Cj  are  conditional  processes  of  the  form 

Cj\Xj]  sb  if  qj  then  r,[p,(XJ)]elee  FilAj(XJ)]  P*  ve  non-conditional  processes  of 
the  form 

m  Vi  :  initialsi  -»  Ri(y;)] 

Each  Pj  offers  a  set  of  initial  choices  initials;  and  for  each  choice  y<  that  is  offered,  the 
future  behavior  of  P,  is  P,(y,).  HS  is  the  Hidden  Set ,  the  set  of  events  and  ports  hidden 
from  the  parallel  composition. 

A  behaviorally  identical  process  P[X7,...,X7,...). 

|  A  done-list  is  maintained  for  each  parallel  composition  ||  {P,[X,],  •••}  that  has 
already  been  computed.  Upon  getting  a  call  for  performing  parallel  composition,  the 
done-list  is  first  consulted. 

•  If  the  requested  parallel  composition  is  in  the  done-list ,  return.  Else  enter  it  in  the 
done-list  and  proceed  as  follows. 

•  Combine  all  conditional  processes  into  one  conditional  process  C.  Combining  two  con¬ 
ditional  processes  is  done  as  follows: 

Ci  [XT]  =  if  ?i  than  Fi^XT)]  alaa  Pi[hi(XT)] 

C2PQ  ss  if  q2  than  TsIftCXJ)]  alsa  FalMXji)] 

C,[X7]  ||  C2(X2]  »  if  (qi  A  q2)  than  2i[pi(XJ)]  || 

alsa  if  (gi  A  not(q7))  than  Ti [^x (XT)]  ||  FalM^a)] 
else  ...etc.  ( all  four  combinations) 

a  Now  we  are  left  with  the  task  of  computing  Hide  HS  in  ||  (P,[XJ),...,  C}.  Let  C  be  of 
the  form 


Output: 

Method: 


if  91  than  Ci[pi(XT)]elsa  if  q2  than  C2[p2(XJ)]etc. 

II  {Pi[X^,...,  C)  reduces  to  a  conditional  process  with  q;  as  the  conditions.  This  condi¬ 
tional  has  in  it  parallel  compositions  of  the  form  ||  {P,[X7),  C<}.  that  is  (recursively) 

computed.  Eventually  we  are  faced  with  composing  non-conditional  processes  in  parallel. 
We  take  this  up  next, 
a  Consider  ||  {P,[Xi),...}.  Let  each  P;  be 

I  -  RllfHX)) 

I  - 
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•  Generate  tuples 

T  =<  cof1,  cap,  ...ca*"  > 

i.e.  a  tuple  of  the  Xjth  initial  compound  action  offered  by  Pi,  the  xath  initial  compound 
action  offered  by  Pa,  etc.  This  tuple  T  is  assumed  to  be  the  irreducible  form  arrived  at 
after  applying  the  action  product  rules  of  figure  10.  According  to  the  rule  for  parallel 
composition  Psrcomp  all  such  tuples  would  become  the  initial  choices  of  the  resultant 
process.  Following  such  choices,  the  resultant  process  would  continue  to  behave  like 
II  However  using  the  hiding  information  HS,  we  can 

prune  many  of  these  choices.  In  particular, 


•  those  tuples  T  that  contain  unsynchronized  events  It  that  belong  to  HS  are 
dropped,  and  the  corresponding  arm  of  the  synchronization  tree  is  pruned; 

•  those  tuples  T  that  contain  Ot  that  belong  to  HS  are  replaced  via  the  substitution 
T[Oidle/Ot). 


•  In  computing 

iwipwwn-i 

the  bindings  generated  by  taking  action  products  of  the  members  of  T  are  taken  into 
account.  □ 


A.2  A  Brief  Description  of  the  HOP  Design  System 

Figure  22  illustrates  the  data  flow  diagram  of  the  HOP  design  system.  The  rectangular 
boxes  indicate  functional  units,  and  boxes  with  curved  sides  indicate  intermediate  storage 
units.  Dotted  lines  show  the  flow  of  control,  and  solid  lines  show  the  flow  of  data.  Currently, 
working  prototypes  exist  for  all  the  functional  units  shown  in  this  figure. 

Input  specifications  are  entered  through  text  editors.  File  name  extensions  .ap,  .rp,  and 
.vp  refer  to  absproc,  realproc,  and  vecproc.  Cell  specifications  are  entered  using  the  PPL[33, 
37]  layout  editor  called  Tiler  [20],  (VLSI  chips  will  be  described  in  PPL;  see  [12]  for  links 
between  HOP  and  PPL.)  HOP  specifications  are  compiled  into  FROBS  representations  using 
the  HOP—»FROBS  compiler.  The  algorithm  PARCOMP  can  now  be  applied  on  realprocs  and 
vecprocs  (presently  implemented  only  for  realprocs).  PARCOMP  infers  functionally  equivalent 
absproc  specifications  from  realproc  and  vecproc  specifications.  The  inferred  behavior  will  be 
much  faster  to  simulate. 

The  simulator  preprocessor  compiles  the  FROBS  database  into  a  form  suitable  for  the 
simulator  (under  development).  A  data  type  definition  mechanism  has  been  implemented 
using  FROBS  [25].  During  simulation,  the  simulator  will  be  called  upon  to  evaluate  functional 
expressions  that  compute  new  datapath  states  as  well  as  output  port  values.  These  will  be 
achieved  by  invoking  the  operations  defined  on  the  various  data  types.  FROBS  supports 
daemons  that  can  help  probe  simulation  results,  as  explained  in  section  5.3.6. 
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Figure  22:  Data  Flow  Diagram  of  the  HOP  Design  System 


